home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
BBS Toolkit
/
BBS Toolkit.iso
/
gt_power
/
news0207.zip
/
GTNEWS
Wrap
Text File
|
1991-02-04
|
66KB
|
1,362 lines
╔════════════════════════════════════════════════════╗
║ February 1, 1991 Volume 2, Issue 7 ║
║ ▒▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒ ║
═══════╣ ▒▒ ▒▒ ▒▒ ╠═══════
║ ▒▒ ▒▒ ║
═══════════╣ - Presented by: The Rocky Mountain GT Power Club - ╠═══════════
║ ▒▒ ▒▒▒ ▒▒ ║
═══════╣ ▒▒ ▒▒ ▒▒ N E W S ╠═══════
║ ▒▒▒▒▒▒▒▒ ▒▒ ║
║ GT Newsletter Founded: 1989 ║
╚════════════════════════════════════════════════════╝
Inside this month's edition:
* GT Power 16.00 review
* DCARC - A brand new GT utility
* George Clifford's Shareware Review
* "INSIDE" News from the Rocky Mountain GT Club
* THE TROUBLESHOOTER - Desqview and GT
* Who's Who; New and present club members
* Sysop notes
* * * * * * * * * * * * * *
16.00 -- First Impressions
I was able to try out the new GT software this month, and
was quite impressed with some of the new features, particularly
the ability to download from any directory. Also, of special
interest, was the enhancements to the file transfer window. (The
use of the bar graph in the window was a nice touch).
The addition of more protocol slots was definitely needed.
While I was not able to put GT in a multi-tasking environment, it
is said to be very well mannered under Desqview. For the high-
speed modem users, the new smart result codes work very well,
even if the entries in the result code table are missing or
inaccurate. There are many, many new features in the new GT
package (listed in last month's newsletter). The biggest change
to this update is in the message areas. Messages are now stored
in a much more efficient way. On my test system, I was able to
save about 20% to 30% in the message areas. I don't have a lot
of messages on that system, so I suspect that the percentages
would increase with the amount of message areas. All in all,
16.00 has once again, proven to be a big success. The only
drawback I can see, is that darn delay for unregistered users.
This is probably the biggest factor why more people don't register
GT Power. I would much rather see a semi-functional unregistered
version, i.e. only 2 external protocol slots, a 15-entry phone
directory, and other minor nuisances. The delay destroys the
ability to fully "test" the operation in unattended BBS mode.
Too bad....
page 1
╔════════════════════════════════════════════════╗
║▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ DCArc v2.2 ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓║
╠════════════════════════════════════════════════╣
║ Archive / File door For GT Power 15.50 ║
║ By Diederick F.M. Cools ║
║ ║
║ Copyright (C) 1990-01 by D.F.M. Cools ║
║ All rights reserved. ║
║ ║
║ Address: Diederick F.M. Cools ║
║ Sibeliusstraat 210 ║
║ 5011 JV Tilburg ║
║ Holland ║
║ ║
╚════════════════════════════════════════════════╝
DCARC... What is it?
DCARC is a new door utility for GT host systems, that
allows both, the sysop and the online user the ability to
convert .ZIP files to .LZH, .ARC, .PAK, or .ZOO, or vice versa.
But wait.... that's not all, there is more, MUCH MORE.
As an online user, you have the ability to change your password,
phone number, and address. This fascinating utility does every-
thing the GT main menu does, EXCEPT for upload and download files.
First, you may display the total files and bytes of each directory.
Like the GT Main Menu, you C)hange file areas, L)ist directories,
and see the F)ile descriptions. You also have the benefit of non-
stop listings. As with the GT main menu, you may P)age the sysop.
The output of the prompts in DCARC matches those of the GT menu, so
you always "feel" like you are in GT. DCARC creates its own status
line, including baud rate, level, user name, etc. DCARC comes
equipped with an extensive H)elp system to guide you along. You may
also I)nquire for new files in DCARC, just like GT!
The biggest advantages of DCARC are E)stimating download times,
and "looking" inside of the archived file. Not only are you given
the ability to see inside of archived files, but you may also
check the integrity of the compressed file by issuing the "TEST"
command. The V)iew command will list the contents of the compressed
file, so you can see what all is there. (So much for VIEWARC!)
What else (as if this isn't enough!) does DCARC do? DCARC
will list users by N)ame, H)ome, D)ate or T)oday's users. Similar
to GT, the Y) command will allow you to toggle ANSI and the X)
will give you eXpert mode. The N)on-stop command is also like GT's,
as is the ability to send it into CHAT mode, without going back
to the BBS.
page 2
The "+" will advance one file area and the "-", of course will
go back one area.
Ah, and what would this fine program be without the S)earch
(keyword and/or filename) command? Well, Mr.Cools has thought of
everything, because that function is there as well.
And if you are the sysop of a GT BBS, you are also allowed to
create directories, change directories, delete files, move files,
delete directories, rename files, shell to DOS and open doors from
within DCARC! You can even tailor the DOS prompt through DCARC.
And of course, you may force BIOS screen writes for those of you
that are using Desqview. As a sysop, you are offered a choice of
either Dutch or English menus.
How easy is it to set up as a door? How about this:
C:
CD\GT
DCARC
Notice anything strange?..... NO Doorway, NO CTTY, NO Gateway,
NO door converter, NO NOTHIN'! This has got to be one of the finest
GT utilities that has come along in ages. Shoot, this utility does
not even need ANSI graphics, because the graphics system is built
right in DCARC. But, best of all, it's FREE! Diederick F. M. Cools
simply asks that you send him a post card or netmail message, telling
him that you are using it.
This truly remarkable program is a MUST for any GT sysop that
runs doors. If you don't have this program yet, you MUST pick it up
soon. If you would like a look at this door in action, both 046/000
and 046/001 have it up and running. It is available under the file-
name of DCARC_22.ZIP.
* * * * * * * * * * * * * *
CORRECTIONS:
While every effort is made to keep the contents of these materials
correct and factual, we cannot guarantee this. Any corrections
should be addressed to:
Bill Watts, Editor | Staff Writers: Bill Watts
Denver, Co. | George Clifford
GT NET/NODE 046/000 | Mike Schmieg
303-730-6709 Taylor Albrecht
page 3
╔════════════════════ CURRENT REVIEWS ═════════════════════╗
║ This column is contributed by George Clifford, sysop ║
║ of George's Computer Room, expert on shareware and PD ║
║ programs. George is very experienced and knowledge- ║
║ able when it comes to dealing with BBS software and ║
║ his column is a big asset to the readers of this ║
║ newsletter. ║
║ Bill Watts, editor ║
╚══════════════════════════════════════════════════════════╝
SHAREWARE REVIEW
by
GEORGE CLIFFORD
SysOp of: GEORGE'S COMPUTER ROOM BBS
(303) 344-9547
February 1, 1991
Product: Turbo SNR
Version: 1.0
Author: Curtis Little
Support BBS: Lost at C BBS, (209) 521-2143
Shareware Registration Fee: $25.00 + 2.50 SH
I think that this is the first time that I will have reviewed a
shareware product sporting version 1.0. I generally prefer to see
a product around a while before I use it, let alone recommend it to
others. Computer gurus will generally approach a program at version
1.0 very gingerly, if at all, preferring not to be the victim of bugs
not yet reported. Indeed, some authors have been known to distribute
their first effort at a version higher than 1.0 in an attempt to avoid
the stigma associated with 1.0s. I guess this is somewhat akin to not
having a thirteen floor in a high rise -- you do not want to invite
trouble. However, as everywhere else in life, there are times to make
exceptions to general rules. And this time around, Turbo SNR is the
recipient of the many exceptions I make to life's general taboos.
As a board sysop, I can remember many occasions when I decided to
change words in some of my BBS files, like the time I decided to be
fancy and change "sysop" to "SysOp" in all of my bulletins. When I
did that, I had not yet come upon Turbo SNR, with the result that I
tediously replaced every occurrence of "sysop" with "SysOp" with my
excellent text editor (which allows me to load all the files I want
to work on in a buffer and even permits global replacement) one
document at a time. Never again for me. Now I know that there are
search and replace utilities that can do that chore for me with one
command line entry. And Turbo SNR is a fine example of that type of
program.
Turbo Search & Replace, or Turbo SNR, or SNR in its shortest form,
is a program specifically designed to offer its user extensive
character or string search and replace capabilities either from the
command line or from a batch file operation. The sophistication and
comprehensiveness of this program caught me by surprise mainly because
page 4
SHAREWARE REVIEWS (cont'd)
I was familiar with another search and replace utility that took up
over 100K on my hard disk, and SNR only took up slightly more than
27K. Thus, I was quite impressed to learn that the program sported
over 15 command line options, and permitted many other command line
parameters to control its processing. Indeed, the options,
substitution strings, command files, and file name parameters allowed
on the command line let the user configure the operation of the
program to a fine degree. It even permits the user to overcome the DOS
command line limitation of 127 characters through the implementation
of command files.
The command line parameters allowed, range from the one stripping
the high bit from every character in the input file(s), to permitting
interactive mode in its operation. In between you can specify whether
to backup the files before they are processed; ignore case when
searching; listing each of the lines that contained a match to at least
one of the substitution strings to invoking the use of a special table
to speed up the processing. In addition, there are many more options
designed to facilitate the search and replace function of this
program. One nice feature, demonstrating the flexibility built into
the program by the author, is the fact that there is no required
sequence in which you must enter the command line parameters. This is
a great help to those of us who don't always stop to memorize the
required syntax of a command.
This program epitimizes simplicity in operation, yet provides
capabilities that DOS users would view as extremely sophisticated,
such as the ability to use Regular Expressions in the search. Don't
worry if you do not know what Regular Expressions are, since few non-C
programmers and non-UNIX afficionados have probably ever confronted
them. However, once learned and appreciated they give the user very
tight control over a search and replace operation. But the program is
very usable even for those who do not want to delve into the domain of
Regular Expressions. Replacing a specified string wherever it occurs
in 1000 files containing the file extension of .BBS is as easy as
SNR -s "sysop=SysOp" *.BBS. And the true DOS diehards are even given
the flexibility to use a "/" instead of the "-" to denote the option
switch.
The program, found under the name of TSNR1.ZIP on many bulletin
board systems comes with complete documentation in the shareware
package. Impressively, the documentation contains a very useful
index, something that too many shareware authors bypass to expediency.
It also contains an appendix outlining the various informational,
warning, and error messages that a user might encounter when using
the program. And equally as thoughtful, is the inclusion by the author
of a Quick Reference Card to assist the user. The only disappointment
for a shareware package is the author's method of encouraging
registration.
Non-registered users must put up with the inconvenience of
pressing a different key or keys every time they start the program up
to bypass the pause at the opening screen. Although GT'ers might not
find it as objectionable as the non-registered GT Power method of
page 5
SHAREWARE REVIEW (cont'd)
increasing the pause delay the more you use a program. However, this
method is more insidious. It effectly acts to cripple the batch
processing feature for users since the batch file cannot run
unattended using the unregistered version. The $25 ($27.50, including
the shipping and handling fee) registration fee removes this annoyance
and also entitles the user with preferential treatment on the author's
support BBS. For an additional $10, the author will send you the
next major upgrade through the mail. All upgrades appear to be
available to registered users from the author's support board for a
fee of $5.00, not a great upgrade policy considering you have to also
pay the telephone charge to get the upgrade. However, even the
non-registered users are allowed to use the board and submit requests
for assistance to the author.
Even if you only use this utility infrequently, the time you save
replacing characters or strings located in several files may more
than return any investment you might make in the registration of the
product. The author closes his documentation with the statement that
"Your imagination's the limit using Turbo SNR!" I do not think you
will be disappointed with this fine shareware product.
* * * * * * * * * * * * * * * *
Other Shareware Releases
GTZ VERSION 1.0
A new external protocol for use with GT
Paul Meiners has recently released a brand new protocol based
on the Zmodem program. When used with GT Power, the sysop is
able to see who is on line while the Zmodem transfer is in
progress. This new module also includes a FILELIST, so that
the sysop may monitor the transfer. I have used this new
protocol extensively on my 16.00-based system, and am currently
testing it on my 15.50 system. I will let you know how well it
works with 15.50 next month. Here is the screen presented by
GTZ:
══════════════════════════════════════════════════════════════════════════════
GTZ 1.0, GT Power Zmodem Module. File List
(C) Copyright 1990 by P&M Software Co. ════════════════
All Rights Reserved 1. CAAEDW.ZIP
2. CAAOAK.ZIP
COM Port 1, Baud Rate 19200, RZ 3. CLEARL.ZIP
4. DRWY212.ZIP
21:52:54 1:10 Est
Zmodem Receive 21:57:34 5:40 1689 cps
Filename: DRWY212.ZIP
Filesize: 181379
Byte Count: 164864
Last Error:
At Byte:
Error Count:
══════════════════════════════════════════════════════════════════════════════
GTZ is packed with GT 16.00 or is available from
some GT BBS's, under the file name of GTZ10.ZIP.
page 6
" I N S I D E " -- Local GT News
Rocky Mountain GT Power Club
▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
▓▓▓▓ ╔═══════════════════════════════════════════════════════════════════╗ ▓▓
▓▓░░ ║ REMINDER ║ ▓▓
▓▓░░ ╠═══════════════════════════════════════════════════════════════════╣ ▓▓
▓▓░░ ║ Rocky Mountain GT Power Club Bi-monthly Meeting ║ ▓▓
▓▓░░ ║ ║ ▓▓
▓▓░░ ║ Where : 4110 Hale Parkway, Meeting Room in Denver, Co. ║ ▓▓
▓▓░░ ║ When : 7:00 PM, Thursday, February 7, 1991. ║ ▓▓
▓▓░░ ╚═══════════════════════════════════════════════════════════════════╝ ▓▓
▓▓░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░▓▓▓▓▓
▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
All RMGTPC members are reminded that we have our regular bi-monthly
meeting February 7, 1991 at 7:00 pm. The address is 4110 Hale Parkway,
at the southeast corner of E. 12th Ave. (Hale Pkwy) and Albion Street.
A map follows......
^
│ │
│ │ I - 70
N ──────┼───────────────────────────────────────
│
│
│ E. Colfax Ave.
──────────────┼───────────────────────────────────────
C │ 12th Ave.
O ├────\
L │ * \H P
O.│ ^ \A K
│ | \L W
│ | \E Y
──────────────┼───────────────────────────────────────
│ | E. 8th Ave.
B │ |
L │ └ 4110 Hale Parkway (SEC 12th Ave. & Albion St.)
V │ in the Party Room
D.│ February 7, 1991 7:00 pm
Please park on one of the nearby streets!
Also, if you have any friends that are interested in GT Power,
be sure to bring them along.
Agenda items will include an in-depth look at GT under Desqview.
A functional GT BBS will be on hand, demonstating the powerful
use of multi-tasking while running a BBS.
page 7
" I N S I D E " -- Local GT News (cont'd)
The President's Corner
by
Taylor Albrecht
I'd like to thank my mother, my father, all of my immediate and ext-
ended family, everyone I've ever met...
No, really. Thanks to the vast membership that voted for me as
President of the Rocky Mountain GT Power Club; all 4 of you!!
Unfortunately my thoughts for this first column seem to be directed
more toward world events. So I feel that I must say something.
I suspect most of you were similarly awestruck and well, quite
frankly, scared as you watched the events unfold before your eyes on
Wednesday, January 16. Once again, we are fighting for freedom; not
only ours but the world's as well. Personally, I'd like to express
my gratitude and support for the 450,000+ troops in the theater. May
they complete their mission swiftly and safely, and return home to a
proud nation. Several members of the GT community have been called to
duty in this conflict, and I wish them well. Their success or failure
directly impacts our ability to provide BBS services in the long term.
Now with that off my chest, on to more pleasant things.
What is the Rocky Mountain GT Power Club (RMGTPC)? To me, it's a
loosely organized group of strange people who have two common threads:
Computers and GT Power Communications.
I've attended all of the club meetings thus far, and have met several
different folks as a result. For the most part, we've had lots of fun
and received important support and information. These meetings are
very informal, and give us a forum to exchange ideas and help one-
another. While the informality is good, we sometimes run out of steam,
which leads me to express the goals I have set for the RMGTPC during
1991 as its President.
My number one goal: To make the Club meetings even more interactive
and beneficial to attendees. One action planned to meet this goal is
to encourage everyone to bring two floppies to the meeting; one full of
page 8
" I N S I D E " -- Local GT News (cont'd)
Shareware/PD programs worth sharing with others that are not readily
available in the local network, and one to take home same. While it
probably need not be said, our meetings are NOT for the illegal exchange
of commercial software, so don't bring any.
The second action to be taken to meet this goal is to have actual demon-
strations of GT and related software. The February meeting will feature
a demo of GT under Desqview, presented by Bill Watts. Several more
ideas are under consideration for the demos.
Another goal, which is closely tied with Number One, is to increase over-
all participation in the Club, including increased attendance at meetings.
To meet this goal, we will consider rotating meeting locations among
regular attendees, perhaps in conjunction with the demonstrations. In
addition, we will more actively encourage and solicit input from our
out-of-state members to get a sense of what the Club means to them.
Finally, the Club Officers will embark on a telephone campaign to draw
more attention to the meetings among Denver-area members.
Finally, I would like to foster interactive cooperation and promotion of
member GT BBSs. I will encourage all sysops in the Club to include a
logon/logoff bulletin with a list of GT BBSs which are identified as
active members of the Club. Bill Watts has given us the lead as far as
promotion, and we all should be following him.
In addition to the regular bi-monthly meetings, we will have the Second
Annual Rocky Mountain GT Power Club Picnic in August. Hopefully we will
attract some out-of-state GTers to this one, making it a premier gathering
among the Network.
I'm excited and encouraged about 1991, which is shaping up to be a great
year for the Club. With your help, we will become a premier, laid-back
user group making an impact.
SYSOP NOTES:
REMINDER TO PARTICIPATING SYSOPS
Don't forget to put the following message on your
GTSYSID.BBS file:
"A member of the Rocky Mountain GT Power Club"
Callers will then know that you are an active member of
this elite users group.
page 9
" I N S I D E " -- Local GT News (cont'd)
NETCOMM BBS
NetComm BBS is now operating 24 hours per day under Desqview.
This has greatly improved the turnover time for mail processing
and file updating. Sysop Bill Watts now has more time to spend
on the Weather and Ski doors. Bill recently released the new
Colorado Ski-line door utility. A much improved version, it
gives more information, including the distance from Denver,
the percentages of Novice or Expert Ski areas, etc. In addition
to the new Ski door, an echo conference (E02/107) has been added
to enhance the Ski door. There are currently 13 systems running
the Ski-door, most of them out of state. If you are interested
in running Colorado Ski-line on your BBS, please send a netmail
message to Bill Watts at 046/000. This new version is capable
of running under Desqview, Doorway, Gateway or standalone.
(Special thanks to Taylor Albrecht for trouble shooting the
Weather door!) NetComm now has over 500 users and 122 echo
conferences.
VALUECOMM BBS
Taylor Albrecht, sysop of ValueComm BBS, states that he now has
over 100 regular users accessing the system. This is because
of the recent additions to his system including the DCARC door,
the File Wish List door, and the steady influx of international
callers interested in the Flight Simulator programs on his BBS.
Taylor reports that his daily calls have doubled in the past
several weeks, due mainly to his highly successful Flight Simulator
echo conference. Seems to be a lot of Hawaiian and Australian
callers as of late. There are now 36 echo conferences available
at ValueComm BBS. Taylor has also recently installed the new
DownLoad Counter in his FILES.BBS's.
EJC DATA SYSTEMS
EJC Data Systems is functioning properly. It is now able to
function completely unattended. The sysop only has to answer
pages and view the message areas daily. The Sysop of EJC is still
trying to complete the new Doors control program for GT. He is
hoping to release the program for Beta testing by the end of
January. The Missing Children's Echo is functioning properly and
information will start being placed into the area regarding missing
children.
The Sysop of EJC has been placed on recall to the U.S. Army. If
this should occur, he will notify all the users and sysops
associated with GT. Let's hope this conflict ends soon so he can
remain here.
page 10
" I N S I D E " -- Local GT News (cont'd)
THE LENSMAN
Greg Bradt recently added a second 40MB hard drive to his system,
bringing the total disk capacity to 80MB. He also recently added
a Courier HST modem, but 9600 baud is only available for netmail,
although ARQ error correction is always available. Greg has also
expanded the main system memory from 2 to 5MB.
Another recent change was in his multitasking setup, converting
from DesqView to Windows 3.0. There have been some minor problems
with the implementation, with system lockups increasing from
approximately monthly (under DV) to approximately weekly (under
Windows). Greg suggests "Maybe someday we'll get a truly bug-free
multi-tasker".
THE HOMEPORT / THE CORSAIR
Stephen Ricciardelli reports that everything is going just fine
on his two systems, with the exception of MEGAREAD and BGPACK.
If you are familiar with these two programs, why not lend Steve
a hand. The Homeport and The Corsair are in the top 3 echomail
systems in the world, second only to 032/001.
VOYAGER II
(Did not report)
THE REFRIGERATOR DOOR
Sysop Mark Pearsall reports that he has successfully set up doors
on his BBS. His echo conference (AT&T PC6300) is also doing quite
well.
OBITER DICTUM
Mike Schmieg, sysop of Obiter Dictum reports that all is well on
both his systems. Mike, as most of you know, is the GT/DV
expert. Please see his DESQview/GT article in the TROUBLESHOOTER
section of this newsletter. Thanks for the contribution, Mike!
THE MERRIE TEES'
(Did not report)
THE ZONE
I am sad to report that THE ZONE BBS, operated by Mark Street was
destroyed by fire, as was his home. If you would like to help
Mark out, recovery donations are being accepted by Bill Watts,
Treasurer of the Rocky Mountain GT Power Club. Speaking for
all of us in the club, I hope Mark is able to recover quickly
from this disaster.
page 11
" I N S I D E " -- Local GT News (cont'd)
THE OBLIVION CONNECTION
(Did not report)
SUNSET INN
The Sunset Inn is the newest addition to the Rocky Mountain GT
Power Club. Sysop Keith Coyne and the Sunset Inn are available
24 hours at 9600 baud. The BBS phone number to our newest member
is 606-283-5459 in Florence, Ky.
SUNSTROKE BBS
Sunstroke operator Louis Moritzky reports that his new 33mhz 386
will arrive in about 2 weeks. The new system will have two USR
14.4k HST's and at least 600 MB's of file area. GT 16.00 should
be operating there by the time this newsletter is released.
AMI-OASIS
(Temp Down)
WIZARD'S LAIR
(Did not report)
Sysops: If you have news about your system, be sure to forward the
information to 046/000 before the 1st of each month.
W H O ' S W H O ?
Two new members were admitted to the Rocky Mountain GT Power
Club. They were:
Keith Coyne, Sysop - Sunset Inn Florence, Ky.
Steve Albrecht Littleton, Co.
Please welcome these new members into the club at your earliest
convenience.
page 12
OTHER GT NEWS
These are new files to the 046 network here in Denver:
Be sure to pick up your copies today!
FILENAME Kb DATE DESCRIPTION
----------- --- -------- ----------------------------------------------
BGAPL10.ZIP 39 01-23-91 Tells GT sysop when someone applies for access
| to a private message area.
COLOSKI2.ZIP 29 01-26-91 COLORADO SKI-LINE, ver. 2.0 works with any BBS.
| Door utility works on any BBS that can use Gateway or Doorway, Desqview
| compatible. Displays current snow conditions at Colorado Ski resorts.
| Data files are file attachable through GT netmail.
DCARC_22.ZIP 111 01-21-91 Excellent archive utility for GT BBS's. You may
| convert any archive to another type, estimate download times, test file
| integrity, read docs without downloading. For a look at this amazing
| program, open O)nline Door #4. GT 15.50 specific.
DLC22.ZIP 58 01-21-91 Download Counter for GT FILES.BBS.
EMT111.ZIP 44 01-22-91 Echomail tracker, very good, bug fix.
FILES_DB.ZIP 16 01-28-91 FILES Data Base for GT 16.00 only. Keeps track
| of all files, avoids duplicate uploads.
FM200.ZIP 22 01-23-91 File Mail II, moves programs and files during
| nightly netmail sessions, between GT nodes. GT 16.00 specific.
FMAIL301.ZIP 19 02-03-91 Fastmail, version 3.01, for GT 16.00 only. Gives
| the user the ability to download mail, and read at a later time.
GETGL10.ZIP 12 02-03-91 Asks for .GL report on certain days of the week.
GL103.ZIP 26 01-22-91 SmartGL report maker, bug fix. For GT Netmail.
| Creates reports of echo bag status and sponsors.
GT1600_1.ZIP 139 01-08-91 GT Power Communications, ver 16.00 1/5
GT1600_2.ZIP 168 01-08-91 GT Power Communications, ver 16.00 2/5
GT1600_3.ZIP 69 01-08-91 GT Power Communications, ver 16.00 3/5
GT1600_4.ZIP 108 01-08-91 GT Power Communications, ver 16.00 4/5
GT1600_5.ZIP 73 01-08-91 GT Power Communications, ver 16.00 5/5
GTH-035.ZIP 141 01-08-91 Oliver Bell's GT setup program.
GTDM11.ZIP 13 02-03-91 GT Diskmeter, sends message to GT 16.00 sysop,
| with bar graph displaying available file space on drive(s).
GTREAD12.ZIP 104 02-03-91 Online mail reader for use with Fastmail program.
| GT 16.00 specific.
VBASE130.ZIP 39 02-03-91 Virus data base, online door for GT.
USAGE300.ZIP 75 02-03-91 Creates bulletins using bar graphs for GT Power
| 16.00 systems only.
WDFIDO22.ZIP 62 01-13-91 Colorado Weatherline, ver 2.2 for FIDO systems.
| Displays weather maps and forecasts of the current Colorado weather,
| door utility, automatic BBS updates.
WDGT22.ZIP 63 01-13-91 Colorado Weatherline, ver 2.2 for GT systems.
| Displays weather maps and forecasts of the current Colorado weather,
| door utility, automatic BBS updates.
XTRGB12.ZIP 21 01-08-91 Log Extract Program for GT.
XTRGT22.ZIP 26 01-08-91 Log Extract Program for GT.
page 13
* EDITORS'S NOTE: Special Thanks to Mike Schmieg for helping out by
writing this month's TROUBLESHOOTER.
" T H E T R O U B L E S H O O T E R "
GT Under DESQview
by Mike Schmieg
DESQview is a very versatile and powerful multitasker that is
suited for BBS operations. There are many areas to be wary of in the
setting up of a DESQview system however. DESQview is very hardware
sensitive. It will work well on almost any 386 system, whether an SX or
a DX, but its use is generally limited on 286 machines unless that
machine is equipped with an All Charge Card or similar hardware
modification and is equipped with either EEMS or hardware implemented
LIM-4 memory. Only one 286 machine comes properly equipped for DESQview
to my knowledge and that is the AST Premium 286. 8088 machines will
work well with DESQview if they are equipped with LIM-4 or EEMS and set
up with 128 or 256k on the motherboard with the balance of the 640k
conventional memory being backfilled from the EXPanded memory. However,
8088 machines are often too slow to efficiently allow heavy duty
multitasking to occur without problems and a BBS is often heavy duty
multitasking.
Once you have your machine equipped for DESQview and you have
installed the program itself, you must fine tune your applications. GT
16.00 is now DESQview aware and may be set up fairly easily. Older
versions of GT are not DESQview aware and GT must be set to write
through the BIOS instead of directly to the screen. While this results
in slower GT operations, it prevents the GT screens from bleeding
through to other applications that you may be running in the foreground.
With 16.00, you tell GT to not use the BIOS screen writes, but you tell
DESQview that the program does not write directly to the screen. Since
16.00 is DV aware, it writes to the DV screen buffer rather than to the
screen itself. This allows faster writes which both you and your users
will note.
Clock ticks under DV are a matter of preference and vary from
machine to machine. I use 3-3 on my 386-20 and on my 286-10, but others
prefer 1-1 to 4-4. Avoid the defaults that DV uses of 9-3. This can
result in delays for background operations which might cause certain
functions, especially xmodem transfers, to time out and possibly cause a
carrier drop. Everyone has a different way of determining clock ticks,
but I look for a combination of screen smoothness in the foreground
application and performance. I usually gauge performance with a test
program like Norton's SI (the older one, not the 5.0) When I get my
maximum performance number in the foreground window, I feel that I have
optimized the system. Remember that for every tick you give a
foreground application, the background must sit idle. Also, if you have
a large number of active windows open at any time, your background
page 14
THE TROUBLESHOOTER (cont'd)
operations are sharing as well which may cause slow downs in the BBS
window. You may want to look for TAME to help in this regard. TAME is
a program that sits in front of other programs that are somewhat ill
behaved under DV and causes them to give up clock ticks when they are
not active, thus speeding up the rest of the system. GT 16.00 does not
require TAME since it is DV aware, but using TAME with Lotus or
WordPerfect will help the BBS window run better.
Many people have expressed difficulty with doors under GT and
DV. DV has difficulty with the CTTY command. The best way around this
is to use Marshall Dudley's DOORWAY. There are a number of programs
available to convert the GTUSER.BBS file to a DOORWAY readable file.
Which one you prefer depends upon the complexity of the doors you run.
The GTPCB series works well with games. GT-DRWY is adequate for most
simple doors and is the one that I use. DOORWAY has many other
benefits, not the least of which is being able to run many programs
remotely, similar to PC-ANYWHERE, but that goes beyond the scope of this
report.
Remember to overlay your doors and your external protocols to
avoid the possibility of running out of memory in your GT window. Allow
at least as much memory as GT plus your door will use and then add a bit
more. I run mail successfully, both crash and regularly scheduled
events, in a DV window and I don't switch windows to do it. I use a 530
k window with no problems. If a GT window bombs and you get no other
message from the system, memory allocation is always the first place to
look.
DV has a very good script capability and that, combined with
some of the excellent utilities available for DV give you a lot of
potential. For instance, on my 286, I tend to run GT in the 2nd window
to avoid the dreaded NON-SWAPPABLE WINDOW message (running it in the
second window forces more of it into EXPanded memory instead of
conventional which might be needed to open other windows). However, DV
does not like a reboot command from any window other than the first
window. I therefore use a script at 3:45 am every morning on the
schedule bbs which causes the GT window to close, causes the first
window to be closed and opens a new first window to copy over a new
autoexec.bat and a new config.sys and reboots the machine. I use LOAD,
a program which causes DV to open another program as a window and I use
Bob Camp's DELAY to cause a delay in those new windows to permit the GT
window to close properly. The possibilities are endless.
While this may not be useful for everyone as every machine will
have different requirements, here is the PIF that I use for my GT host
on the 386. If nothing else, this might make a good starting place for
problem solving:
page 15
THE TROUBLESHOOTER (cont'd)
Change a Program
Program Name............: GT Power Host (Obiter Dictum)
Keys to Use on Open Menu: IO Memory Size (in K): 530
──────────────────────────────────────────────────────────────────────────────
Program...: iokcug.bat
Parameters:
Directory.: c:\gt
──────────────────────────────────────────────────────────────────────────────
Options:
Writes text directly to screen.......: [N]
Displays graphics information........: [N]
Virtualize text/graphics (Y,N,T).....: [T]
Uses serial ports (Y,N,1,2)..........: [1]
Requires floppy diskette.............: [N]
Change a Program Advanced Options
System Memory (in K).......: 0 Maximum Program Memory Size (in K)..:
Script Buffer Size.......: 1000 Maximum Expanded Memory Size (in K):
Text Pages: 1 Graphics Pages: 0 Initial Mode: Interrupts: 00 to FF
──────────────────────────────────────────────────────────────────────────────
Window Position:
Maximum Height: 25 Starting Height: 15 Starting Row...: 45
Maximum Width.: 80 Starting Width.: 38 Starting Column: 41
──────────────────────────────────────────────────────────────────────────────
Shared Program
Pathname..:
Data......:
──────────────────────────────────────────────────────────────────────────────
Close on exit (Y,N,blank)......: [N] Uses its own colors..............: [Y]
Allow Close Window command.....: [N] Runs in background (Y,N,blank)...: [Y]
Uses math coprocessor..........: [N] Keyboard conflict (0-F)..........: [0]
Share CPU when foreground......: [Y] Share EGA when foreground/zoomed.: [Y]
Can be swapped out (Y,N,blank).: [N] Protection level (0-3)...........: [1]
Hope that this helps some of you. If any of you have specific questions,
remember that we have several fine echo conferences that deal with this
topic, including GT UNDER DV, UK-DESQVIEW SUPPORT and my own MULTITASKING
CONFERENCE.
page 16
EXTRA! EXTRA! EXTRA! EXTRA! EXTRA! EXTRA! EXTRA! EXTRA! EXTRA! EXTRA! EXTRA!
A Word from US Robotics
( Downloaded from the US Robotics BBS)
Not long ago, many data communicators thought that dial-up modem manufacturers
had pushed transmission speeds to the limit with the introduction of 2400 bit
per second (bps) modems. Recently, however, several manufacturers have
creatively combined relatively mature techniques of data transmission with
newer technology and have introduced 9600 bps modems.
Unfortunately, a widely accepted standard for full duplex 9600 bps
transmission as defined by the International Consultative Committee for
Telegraphy and Telephony (CCITT) does not yet exist (the CCITT is currently
considering proposals for a new 9600 bps dial-up standard). This means that
today's 9600 bps modems do not offer cross-manufacturer compatibility. The
CCITT HAS endorsed a half duplex and a full duplex 9600 bps standard, but to
date implementations of these relatively flexible standards have been
proprietary, i.e., even the "standardized" modems from different manufacturers
are not compatible.
All this means that modem users who want to enjoy the dream speed of 9600 bps
must weigh the pros and cons of each 9600 bps technique before committing to a
particular 9600 bps design. This paper was written in an effort to provide
typical modem users with enough technical information and insight that they
will be able to consider the new 9600 bps modems from the position of an
educated consumer and not have to rely on information gleaned from sales
brochures and advertisements. It should be noted that the author, Wes Cowell,
is an employee of USRobotics.
THE ROAD TO 9600
High speed data communications via the dial-up phone network is limited by the
available phone line bandwidth and by random channel impairments. Just as the
diameter of a pipe limits its liquid flow capacity, so does the telephone
channel bandwidth limit its data flow capacity.
The roughly 3000-Hz available in the telephone bandwidth poses few problems
for 300 bps modems, which only use about one fifth of the bandwidth. A full
duplex 1200 bps modem requires about half the available bandwidth,
transmitting simultaneously in both directions at 600 baud and using phase
modulation to signal two data bits per baud. "Baud rate" is actually a
measure of signals per second. Because each signal can represent more than
one bit, the baud rate and bps rate of a modem are not necessarilly the same.
In the case of 1200 bps modems, their baud rate is actually 600 (signals per
second) and each signal represents two data bits. By multiplying signals per
second with the number of bits represented by each signal one determines the
bps rate: 600 signals per second X 2 bits per signal = 1200 bps.
In moving up to 2400 bps, modem designers decided not to use more bandwidth,
but to increase speed through a new signalling scheme known as quadrature
amplitude modulation (QAM).
page 17
EXTRA! (cont'd)
In QAM, each signal represents four data bits. Both 1200 bps and 2400 bps
modems use the same 600 baud rate, but each 1200 bps signal carries two data
bits, while each 2400 bps signal carries four data bits:
600 signals per second X 4 bits per signal = 2400 bps.
A technique known as adaptive equalization enables 2400 bps modems to adapt to
phone line impairments call-by-call. Essentially, if the modem is experiencing
problems with a noisy line, it looks for a "sweet spot" in the bandwidth and
attempts to avoid troublesome frequencies. This technique makes 2400 bps
modems more tolerant of line noise than their 1200 bps counterparts that use
compromise equalization (a one-size-fits-all approach).
While these advanced modulation and equalization techniques in 2400 bps modems
provide for double the data rate of 1200 bps modems, they also result in a
design at least four times more complex than 1200 bps modems.
Which brings us to the problem of designing a 9600 bps modem.
Jumping to 9600 from 2400 bps is several orders of magnitude more complicated
than going to 2400 from 1200 bps. Telephone network characteristics make it
highly unlikely that success will be had in extending the "data signal
alphabet" (number of bits represented by each signal) beyond four bits per
signal.
Instead, modem designers must increase the bandwidth that is to carry the
signal, and this presents a very big problem. In fact, at speeds of 4800 bps
(1200 signals per second), the transmit and receive channels must be expanded
to the point where they actually begin to overlap. A 9600 bps "band"
requires roughly 90 percent of the available bandwidth, making it impossible
to have two-way communication without the bands interfering with each other.
A helpful analogy to the problem might be to consider a two lane highway:
traffic must flow in both directions simultaneously, but to carry more cars
per unit of time, highway designers must either increase the number of lanes
in each direction or widen the two lanes to accommodate driver error with a
margin of safety. Unfortunately, these options are not available to modem
designers as the available bandwidth is of a fixed size.
With these considerations and limitations in mind, let's examine three basic
ways to accomplish full duplex (two-way) 9600 bps communications: echo
cancellation, virtual full duplex (achieved by half duplex systems), and
asymmetrical frequency division.
ECHO-CANCELLATION
This method solves the problem of overlapping transmit and receive channels.
Each modem's receiver must try to filter out the echo of its own transmitter
and concentrate on the other modem's transmit signal. This presents a
tremendous computational problem that significantly increases the complexity
-- and cost -- of the modem. But it offers what other schemes don't:
simultaneous two-way transmission of data at 9600 bps.
page 18
EXTRA! (cont'd)
The CCITT "V.32" recommendation for 9600 bps modems includes echo-
cancellation. The transmit and receive bands overlap almost completely, each
occupying 90 percent of the available bandwidth. Measured by computations per
second and bits of resolution, a V.32 modem is roughly 64 times more complex
than a 2400 bps modem. This translates directly into added development and
production costs which means that it will be some time before V.32 modems can
compete in the high- volume modem market.
Despite the fact that V.32 is a recognized standard, it is uneconomical and
unnecessarily complex for personal computer datacomm applications that simply
don't require simultaneous two-way 9600 bps transmission.
HALF DUPLEX SYSTEMS
(Virtual Full Duplex)
Half duplex solutions devote the entire bandwidth to 9600 bps in one direction
at a time, and "ping-pong" the data flow back and forth to simulate full
duplex. This is potentially the simplest scheme. Its performance is
acceptable in data transfer applications that don't involve user interaction,
i.e. file transfers. Even so, advanced error-control protocols that require
ACKnowledgments to be sent in response to received data blocks generate a high
number of "line reversals" which greatly impair overall data throughput. In
short, the benefit of higher speed is so significantly compromised by line
reversals in half duplex sessions that the net gain in data throughput may be
marginal at best.
If users want to operate in an interactive mode, their data must be sent to
the remote computer, the data channel must be reversed, and then the data must
be echoed back. This process results in significant turn-around delays which
can be very frustrating to users.
Half duplex modems of this kind are most often based on CCITT recommendation
V.29 for half duplex 9600 bps transmission on the dial-up network. V.29 based
data pumps used in facsimile systems are available as LSI chip sets, providing
a short-cut to modem manufacturers, particularly to companies that don't
develop their own modem technologies. But the major problem is that the V.29
modulation scheme has been outdated by the fact that it operates in a half
duplex mode and doesn't provide good signal to noise performance. The V.32
recommendation, which operates in a full duplex mode and employs Trellis
Coding Modulation offers greater throughput and a greater immunity to channel
impairments.
To the best of my knowledge, modems employing V.29-based modulation include
products from Racal-Vadic, Comspec, Develcon, Gamma Technology, Microcomm, and
Electronic Vaults, Inc. (EVI). These modems, however, are NOT mutually
signal compatible -- cross-manufacturer compatibility does not exist.
Another modem in the half duplex category, but not based on V.29 modulation,
is the Telebit Trailblazer (R), which uses a proprietary modulation method.
Trailblazer is based on a multi-carrier technique. Conceptually, the
transmission channel is divided into many (512), independent, very narrow
page 19
EXTRA! (cont'd)
channels (think of our two-lane highway and imagine it as having 512 very
narrow lanes (say, for bicycles) going in one direction and you've got a fair
idea of how Trailblazer divides the bandwidth). The main advantage is that no
receiver adaptive equalizer is needed because each channel is very narrow
compared to the overall channel bandwidth.
Further, in the Trailblazer modulation scheme, the modulation rate in each
narrow channel can be changed somewhat independently. Trailblazer is
different from many other modems in that the decision to fall back to lower
speeds is built into the modem protocol, rather than controlled by the user's
computer port. It is claimed that in the face of channel impairments,
throughput can be adapted gracefully to channel conditions. Traditional
modulation systems would have to fall back in larger steps. But there are
three inherent MAJOR problems:
1) The turn-around delay is very long compared to conventional modulation
techniques because data must be sent in large blocks. A typed character may
take several seconds to be echoed back to the system that sent it. As a
result, the system fails to achieve the illusion of full duplex and is not
really suited to interactive online sessions.
2) The Trailblazer receiver cannot "track" carrier "phase jitter" (phase
jitter can be thought of in terms of "phase shift": think of how the whine of
a race car goes from higher to lower as it passes the viewer -- the frequency
of the sound is said to be "shifted" or "jittered"). Instead of cancelling
out phase jitter (which is commonly encountered on long distance calls) the
Trailblazer can only respond by lowering throughput to gain more immunity to
phase jitter.
3) The ability to transmit at the maximum rate when subject to channel
impairment is considerably less than for conventional modems. There is one
notable exception: the multiple channel technique offers extremely good
immunity to impulse noise because the impulse energy is distributed over
narrow channels. While conventional modems can achieve similar results
through special coding or filtering techniques they rarely implement such
methods.
ASYMMETRICAL FREQUENCY DIVISION
When one considers the nature of most PC datacomm applications, it is realized
that most applications are interactive, involving manual (typed) data entry
from one end and data file transmission from the other end.
Few, if any, PC users can justify using an expensive 9600 bps channel to carry
their typed characters when they realize that 300 bps translates to 360 words
per minute. Assuming one could type 100 words per minute, even a 100 bps
transmission channel would be sufficient.
On the other hand, file transfer should take advantage of the tremendous speed
of the microprocessor. Serial ports are often set at data rates in excess of
19,000 bps.
page 20
EXTRA! (cont'd)
Considering these inherent characteristics, a communications scheme that
incorporated a high speed and a low speed channel would be best suited for
most PC datacomm applications.
Remembering the highway analogy (higher speeds mean wider lanes), one can see
how such a method would grant modem designers a large portion of the
available bandwidth for a 9600 bps channel and still leave enough room to
accommodate a narrow 300 bps channel without any channel overlap.
By utilizing two discreet channels, such a modem would avoid costly, complex
echo-cancellation schemes. And, because the channels carry data in both
directions simultaneously, the communications link is a true full duplex
connection. This means that data entered at one system would be almost
instantaneously echoed back -- eliminating the frustrating turn-around delay
experienced in half duplex sessions.
USRobotics has developed just such a modem. It passes data in one direction
using the V.32 modulation technique (a very robust method that is very immune
to phone line impairments) but employs only a 300 bps channel in the opposite
direction so that the channels do not overlap and echo-cancellation is not
necessary.
The use of the high-speed channel by the two modems is based on data demand.
In most applications, however, "channel swapping" will not be required. For
interface elegance, the modems employ a 4K buffer that allow them to perform
data rate conversion: sending and receiving speeds remain constant between the
modem and the computer -- it is only in between the modems that transmitted
and received data run at different speeds.
For interactive sessions, users are assigned the low-speed channel while the
data sent to them (long mail messages, menus, files, etc.) in the 9600 bps
channel.
For file transfer sessions, the data blocks that make up a file are sent in
the 9600 bps channel while the corresponding ACKnowledgments are returned in
the 300 bps channel. An asymmetric frequency division scheme is ideal for
file transfer where large data blocks (usually several hundred bytes in
length) are transmitted in the high-speed channel and the ACKs (usually only
a few bytes in length) are carried in the low-speed channel.
If a user switches from an interactive mode to file transfer and then back to
interactive mode, the high speed channel is dynamically and automatically
assigned to the system with the greatest data demand.
A BRIEF COMPARISON
Three options exist for data communicators who desire to operate at 9600 bps:
1) V.32-type modems offer a full duplex connection but do so by virtue of
echo-cancellation. This technique is so complex, and has proven so difficult
to employ, that the cost for such modems will remain prohibitively high and
their implementation a delicate task for some time to come.
page 21
EXTRA! (cont'd)
2) Half duplex modems (either V.29 or multi-carrier) offer 9600 bps but the
turn-around delay inherent in half duplex links severely compromise overall
throughput. This degradation of throughput, however, can be more than offset
by data compression techniques assuming the modems in question support
identical compression protocols and are operating on relatively "clean" phone
lines. Both half duplex methods suffer disproportionate degradation on
"noisy" lines: the V.29 modems must spend more and more time in line reversals
as detected data errors increase, and the multi-carrier modems must sacrifice
throughput to gain noise immunity.
3) Asymmetrical Frequency Division offers 9600 bps communications in a true
full duplex implementation. By efficiently utilizing the available bandwidth,
these modems provide users with high speed file transfer capabilities and fast
response in interactive sessions. Because the transmit and receive data
channels do not overlap, expensive echo-cancelling techniques are unnecessary
making these modems economically efficient.
IN CONCLUSION
Until a widely recognized standard is agreed upon by the standards community,
and implemented by several manufacturers, modem buyers must weigh the benefits
and detriments of each 9600 bps scheme.
V.32 would be best where symmetrical, full duplex, synchronous communication
is desired (for example, dial-up HDLC links between multiplexers) and where
the user can modify his software to accommodate non-"AT" command-driven
modems.
V.29 modems would be likely solutions where absolute lowest price is required
and conformance to an international standard (in a very limited sense) is
desired.
Multi-carrier transmission schemes are well-suited to applications that
require maximum one-way throughput and where circuit conditions are known to
be good. This transmission method is also ideally suited for circuits where
immunity to impulse noise is paramount.
Users who most often work with one-way file transfers (PC-to-PC) or with real-
time applications may opt for an Asymmetrical Frequency Division scheme, which
is suited equally well for either application. The elegant approach to the
frequency division (avoiding overlapping bandwidths) also allows these modems
to present a very economical ratio between dollars and bps.
Potential high-speed-modem buyers should also consider the aspects of ease-of-
use, ease-of-implementation, and downward compatibility with existing
implemented standards (the CCITT's V.22bis for 2400 bps, Bell 212A for 1200
bps, and Bell 103 for 200 bps).
page 22
Rocky Mountain GT Power Club Established 01-01-89
╔════════════════════════════════════════════════════════════════════════════╗
║ President: Taylor Albrecht Vice President: Greg Bradt ║
║ Secretary: Sean Burk Treasurer : Bill Watts ║
╚════════════════════════════════════════════════════════════════════════════╝
╔════════════════════════════════════════════════════════════════════════════╗
║ MEMBERS RUNNING BBS's : ║
║ Member Name/ BBS Name/ Sorted by: Max. ║
║ City/State Hours Net/Node Baud Modem # ║
╚════════════════════════════════════════════════════════════════════════════╝
Keith Coyne Sunset Inn 006/000 9600 606-283-5459
Florence, Ky. 24 hours
Mike Schmieg Obiter Dictum 006/004 2400 513-831-2576
Milford, Oh. 24 hours
Stephen Kreyling The Oblivion Connection 006/036 9600 606-781-8303
Ft. Thomas, Ky. 24 hours
Stephen Ricciardelli The Homeport BBS 009/400 9600 602-451-5340
Scottsdale, Az. 24 hours
Stephen Ricciardelli The Corsair 009/401 2400 Private
Scottsdale, Az. Irregular
Perry Alexander InfoStation 032/001 9600 606-269-7136
Lexington, Ky. Mail Hub Only
Louis Moritzky The Sunstroke 040/000 2400 303-361-6106
Aurora, Co. 24 hours
Bill Watts NetComm 046/000 2400 303-730-6709
Denver, Co. 24 hours
Taylor Albrecht ValueComm BBS 046/001 2400 303-388-0336
Denver, Co. 24 hours
George Clifford George's Computer Room 046/002 2400 303-344-9547
Aurora, Co. 24 hours
Bill Watts NetComm II 046/004 1200 Private
Denver, Co. 3 am - 5 am
Rod Duff Ami-Oasis 046/005 2400 SYSTEM DOWN
Aurora, Co. 24 hours
Edward Shephard Voyager II 046/006 2400 303-279-2534
Golden, Co. 6 am -11 pm
Greg Bradt Lensman 046/007 2400 303-979-8953
Littleton, Co. 24 hours
page 23
CLUB MEMBERS (cont'd)
Mark Pearsall The Refrigerator Door 046/008 2400 303-421-4149
Golden, Co. 24 hours
Sean Burk EJC Data Systems 046/009 1200 303-366-2473
Aurora, Co. 5pm - 8am
Mark Street The Zone 080/002 2400 SYSTEM DOWN
Kansas City, Ks. 24 hours
Guy Bentley The Wizard's Lair 088/001 2400 719-597-4722
Colorado Springs, Co. 24 hours
Bill Templeton The Merrie Tees' N/A 9600 719-829-4210
Wiley, Co. 24 hours
Curtis Dinkel The Flashlight BBS N/A 2400 Coming soon!
Woodland Park, Co. 24 hours
╔════════════════════════════════════════════════════════════════════════════╗
║ NON-SYSOP Members: ║
╚════════════════════════════════════════════════════════════════════════════╝
Glen Rhoads Denver, Co. : Dan Boyer Aurora, Co.
Frank Freeman Denver, Co. : Elliott Robb Aurora, Co.
Mike Vendegnia Littleton, Co. : Philip Alexander Denver, Co.
Val Roberts Denver, Co. : Bruce Nunnallee Aurora, Co.
Lee Jarvie Parker, Co. : Kevin McNeece Denver, Co.
Herb McCrystal Morrison, Co. : Tim Crisman Aurora, Co.
David Richards Lakewood, Co. : Mark Milburn Lakewood, Co.
Henrique Barreto Broomfield, Co. : Bob Johnson Denver, Co.
Steve Albrecht Littleton, Co. :
* * * * * * * * * * * *
If you are not a member of the Rocky Mountain GT Power
Club, but would like to join, please contact any par-
ticipating BBS member of the club. There, you will find
information about how to join the club. There is
absolutely NO fee required to join.
* * * * * * * * * * * *
page 24
N E X T M O N T H
1. Shareware Reviews
2. More GT Accessories
3. A closer look at Bimodem
Hints: Origin lines
If you are new to GT BBSing and are wondering how to make those
long origin lines, it is simple. All you need is a text editor
that is capable of margins of 0 to 250 or so. Then simply enter
the information in your SCHEDULE.BBS file.... that's all there
is to it! There are several programs availble to view your
origin line without creating a message first. One of them is
ORIGIN10.ZIP and is available on most GT BBS's.
If you would like to write a column for this newsletter, please
contact Bill Watts at 046/000, 303-730-6709. Writers are still
needed for the TROUBLESHOOTER, a column aimed at helping users
with GT-related problems.
-- see ya next month! --